You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As part of this pull request, DBSchema has been made an optional constructor parameter of DBFunction. Additionally, the logic for deriving the functionName has been updated.
Separating the concerns of function name derivation between DBSchema and DBFunction is beneficial for a few reasons:
Decoupling: By separating these concerns, DBFunction doesn't need to know the details of how the schema name is derived. It just needs to know that it can get a schema name from DBSchema. This decoupling makes the code more modular and easier to change. It also means that changes to how the schema name is derived won't affect the DBFunction class, and vice versa.
Consistency: By centralizing the logic for function name derivation in DBFunction, you ensure that the same logic is used consistently across all instances of DBFunction. This can help prevent bugs and inconsistencies that might arise if different parts of the codebase were deriving function names in different ways.
Flexibility: The DBFunction class can be used with or without a DBSchema. By separating the concerns of function name derivation, you allow for greater flexibility in how DBFunction instances are created.
Code Reusability: The logic for deriving the function name is encapsulated in DBFunction. This means that the same logic can be reused for all DBFunction instances, regardless of whether they have a DBSchema or not.
Ease of Testing: With separated concerns, it's easier to write unit tests for each class. You can test the schema name derivation logic in DBSchema independently of the function name derivation logic in DBFunction.
Separating the concerns of function name derivation between DBSchema and DBFunction leads to more modular, consistent, flexible, and testable code.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As part of this pull request,
DBSchemahas been made an optional constructor parameter ofDBFunction. Additionally, the logic for deriving thefunctionNamehas been updated.Separating the concerns of function name derivation between
DBSchemaandDBFunctionis beneficial for a few reasons:Decoupling: By separating these concerns,
DBFunctiondoesn't need to know the details of how the schema name is derived. It just needs to know that it can get a schema name fromDBSchema. This decoupling makes the code more modular and easier to change. It also means that changes to how the schema name is derived won't affect theDBFunctionclass, and vice versa.Consistency: By centralizing the logic for function name derivation in
DBFunction, you ensure that the same logic is used consistently across all instances ofDBFunction. This can help prevent bugs and inconsistencies that might arise if different parts of the codebase were deriving function names in different ways.Flexibility: The
DBFunctionclass can be used with or without aDBSchema. By separating the concerns of function name derivation, you allow for greater flexibility in howDBFunctioninstances are created.Code Reusability: The logic for deriving the function name is encapsulated in
DBFunction. This means that the same logic can be reused for allDBFunctioninstances, regardless of whether they have aDBSchemaor not.Ease of Testing: With separated concerns, it's easier to write unit tests for each class. You can test the schema name derivation logic in
DBSchemaindependently of the function name derivation logic inDBFunction.Separating the concerns of function name derivation between
DBSchemaandDBFunctionleads to more modular, consistent, flexible, and testable code.